Packaging changes for UI framework support #2245
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Deprecate all UI-framework-specific and platform-specific types in System.Reactive. Add various System.Reactive.Integration.... packages with the replacement types.
It looks like a few tests that fetched DispatcherScheduler.Current used to rely on the Dispatcher already having been created. Up until recently, that was true by random chance. But recent changes, which presumably have affected the order of test execution, mean that's no longer true. These tests should always have ensured a dispatcher was available before starting to run, and now they do.
* Add Obsolete attributes * Add the newly-public (was internal) member of AsyncLock
Change SDK file ref to a version available on the build agent Replace net6.0 with net8.0 Remove uap10.0.18362 from non-legacy components Use .NET SDK PackageValidation for System.Reactive API compatibility check. Initial ADR drafts Use Microsoft.CodeAnalysis.PublicApiAnalyzers in System.Reactive.Net Remove the ApiApprovalTests that are now superceded by the use of package validation for the legacy System.Reactive package, and public API analyzers for the new System.Reactive.Net.
Before, the build system didn't know we are using a custom ref assembly. This meant, amongst other things, that tests no longer built.
This was after all the entire point of this branch.
These crept in from a merge.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes WPF and Windows Forms support from the publicly visible API of
System.Reactive, moving it into newSystem.Reactive.For.WpfandSystem.Reactive.For.WindowsFormspackages. (This only removes them from the compile-time API. These APIs are gone from therefassemblies, but remain in thelibones to ensure binary compatibility.)This resolves #1745
The 'great unification' of Rx 4.0, in which all Rx.NET features were merged into a single NuGet package, has had unfortunate consequences in the long run. In particular, the decision to include UI-framework-specific code in this unification has meant that any application with a Windows-specific TFM for Windows 10.0.19041 or later will, if it uses
System.Reactiveend up with dependencies on both Windows Forms and WPF. The effect of this is that for certain styles of deployment (AoT or self-contained), the build output includes a copy of these UI frameworks. These are tens of megabytes in size, and for applications that are not actually using either WPF or Windows Forms, this is a significant penalty.As long as
System.Reactive's public API includes types that belong to either of these frameworks, it is not possible to remove the transient framework dependency thatSystem.Reactiveimposes on applications that use it. That is why we are effectively removing these features from the publicly visible API. (Removing them entirely would break backwards compatibility. In cases where an application developer uses other components that use Rx, they might not be able to resolve the problems this would cause. This is why we retain the 'removed' API features in the runtime API available in the NuGet package'slibfolder.)